【第91期】前端开发者的代码回顾清单

我们的目的并不是定义一套固有的代码回顾实践方式，而是为回顾者 (reviewer) 提供一份清单。

当然，它也帮助开发者了解在代码回顾时如何扮演好一名回顾者的角色。回顾者本应如此专注于撰写更好更简洁的代码。

因为代码的作者没有进行自我回顾。所以开发者需要一种新的方式——很显然他们可以持续提炼并改进代码。

理念

代码回顾对事不对人 (Code Review is about the code not about the coder)

首先，代码回顾只专注在写出来的代码上。

这种场合最应该做的是确认代码符合既定标准、最佳实践等等，务必回避指责作者的行为。

没有人能够挑战这一原则，不论他是新雇员、老鸟、主管哪怕是 CTO。

我们必须意识到，没有任何代码是足够优秀到不需要回顾的。

同时，这也是分享开发技术技巧的绝佳时机，再顺便探讨一下当下流行的编码方式，何乐而不为呢？

清单

这里的清单是指一套代码回顾时遵循的要点集合。

同时这份清单也会帮助开发者理解哪些东西需要回顾。

0. 编码规范

这件事情排在步骤 0，因为实际上它并不算在清单本身的范畴内：编码规范是需要时刻遵守的。

也就是说，每一名开发者都必须遵循既定的编码规范。

1. 代码质量

A：代码质量能够确保：

B：减少 bug 数量；

C：让每个人都读得懂。

D：前端团队可以通过 JSHint 或 Plato 等类似的工具来监控 JavaScript 代码的质量。

2. 一致性

回顾者要确保写出的代码能够满足需求，正常工作。

3. 简单

A：回顾者要确保代码直接有效的解决了问题。

B：然后我们可以通过 JSHint (详见第 2 条) 来计算条件复杂度。

C：复杂度和 bug 的出现频率是由相关性的。

D：基本上，越是复杂的地方，就越要简化。

4. 可维护性

回顾者确保另一名开发者也可以对现有代码进行快速修改。

回顾者确保代码是 (比如通过一些模式达到) 模块化的，并且变量和方法的命名是清晰的。

HTML 和 CSS 选择器也同样如此。我们必须能够理解 class 或方法表现出的含义。

还要确保一个方法做一件事的原则。

5. 性能

性能问题不仅限于 js 或 css 文件的压缩比率以及对图片精灵的使用。

它还存在于循环、数组操作、DOM 操作等方方面面……

jsPerf 是一个非常棒的工具，它可以在线测试一段代码在各种浏览器中的性能：http://jsperf.com/。